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Foreword 



id , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

x the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



The interface Itf-N, defined in 3GPP TS 32.102 [2], is built up by a number of Integration Reference Points (IRPs) and 
a related Name Convention, which realise the functional capabilities over this interface. The basic structure of the IRPs 
is defined in 3GPP TS 32.101 [1] and 3GPP TS 32.102 [2]. 
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Scope 



The present document (Generic Network Resources IRP: Network Resource Model) defines an Integration Reference 
Point (IRP) through which an IRP Agent' (typically an Element Manager or Network Element) can communicate 
Network Management related information to one or several 'IRPManagers' (typically Network Managers). 

The present document specifies a generic Network Resource Model, NRM (also referred to as a Management 
Information Model - MIM) with definitions of Managed Object Classes. 

The Configuration Management (CM) area is very large. The intention is to split the specification of the related 
interfaces in several IRPs. In addition to the subject IRP, it is expected that IRPs will be defined for functional areas like 
Security management, Software management, Network & Service provisioning, etc. An important aspect of such a split 
is that the Network Resource Models (NRMs) defined in different IRPs are consistent. The Generic Network Resources 
IRP here provides a base for all resource modelling. 

To summarize, the Generic Network Resources IRP main purpose is to define a generic Network Resource Model that 
constitutes a base from which other (more specialized) resource models can inherit or have associations with. 
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[15] 3GPP TS 23.002: "Network Architecture". 

[16] 3GPP TS 32.642: "UTRAN network resources Integration Reference Point (IRP): Network 

Resource Model (NRM)". 



Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply. For terms and definitions not 
found here, please refer to 3GPP TS 32.101 [1], 3GPP TS 32.102 [2] and 3GPP TS 32.600 [14]. 

Association: In general it is used to model relationships between Managed Objects. Associations can be implemented in 
several ways, such as: 

(1) name bindings , 

(2) reference attributes , and 

(3) association objects . 

This IRP stipulates that containment associations shall be expressed through name bindings, but it does not stipulate the 
implementation for other types of associations as a general rule. These are specified as separate entities in the object 
models (UML diagrams). Currently however, all (non-containment) associations are modelled by means of reference 
attributes of the participating MOs. 

Managed Element (ME): An instance of the Managed Object Class ManagedElement. 

Managed Object (MO): In the context of the present document, a Managed Object (MO) is a software object that 
encapsulates the manageable characteristics and behaviour of a particular Network Resource. The MO is instance of a 
MO class defined in a MIM/NRM. An MO class has attributes that provide information used to characterize the objects 
that belong to the class (the term "attribute" is taken from TMN and corresponds to a "property" according to CIM). 
Furthermore, an MO class can have operations that represent the behaviour relevant for that class (the term "operation" 
is taken from TMN and corresponds to a "method" according to CIM). An MO class may support notifications that 
provide information about an event occurrence within a network resource. 

Management Information Base (MIB): A MIB is an instance of an NRM and has some values on the defined 
attributes and associations specific for that instance. In the context of the present document, an MIB consists of: 

(1) a Name space (describing the MO containment hierarchy in the MIB through Distinguished Names), 

(2) a number of Managed Objects with their attributes and 

(3) a number of Associations between these MOs. Also note that TMN (ITU-T Recommendation X.710 [7]) 
defines a concept of a Management Information Tree (also known as a Naming Tree) that corresponds to the 
name space (containment hierarchy) portion of this MIB definition. Figure 1 depicts the relationships between 
a Name space and a number of participating MOs (the shown association is of a non-containment type) 
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Figure 1 : Relationships between a Name space and a number of participating MOs 



Management Information Model (MIM): Also referred to as NRM - see the definition below. 

Name space: A name space is a collection of names. The IRP name convention (see 3GPP TS 32.300 [13]) restricts the 
name space to a hierarchical containment structure, including its simplest form - the one-level, flat name space. 
All Managed Objects in a MIB shall be included in the corresponding name space and the MIB/name space shall only 
support a strict hierarchical containment structure (with one root object). A Managed Object that contains another is 
said to be the superior (parent); the contained Managed Object is referred to as the subordinate (child). The parent of all 
MOs in a single name space is called a Local Root. The ultimate parent of all MOs of all managed systems is called the 
Global Root. 

Network Resource Model (NRM): A model representing the actual managed telecommunications network resources 
that a System is providing through the subject IRP. An NRM describes Managed Object Classes, their associations, 
attributes and operations. The NRM is also referred to as "MIM" (see above), which originates from the ITU-T TMN. 

Node B: A logical node responsible for radio transmission/reception in one or more cells to/from the User Equipment. 
It terminates the Iub interface towards the RNC. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AUC Authentication Centre 

BG Border Gateway 

CIM Common Information Model 

CMIP Common Management Information Protocol 

CMIS Common Management Information Service 

CN Core Network 

CORBA Common Object Request Broker Architecture 

DMTF Distributed Management Task Force 

DN Distinguished Name (see 3GPP TS 32.300 [13]) 

EIR Equipment Identity Register 

EM Element Manager 

FM Fault Management 

GDMO Guidelines for the Definition of Managed Objects 

GGSN Gateway GPRS Support Node 

GMSC Gateway MSC 

GPRS General Packet Radio System 

HLR Home Location Register 

IDL Interface Definition Language 

IRP Integration Reference Point 

ITU-T International Telecommunication Union, Telecommunication Sector 

Iub Interface between RNC and Node B 

LDAP Lightweight Directory Access Protocol 

ME Managed Element 

MIB Management Information Base 

MIM Management Information Model 

MIT Management Information Tree (or Naming Tree) 

MO Managed Object 

MOC Managed Object Class 
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MOI Managed Object Instance 

MSC Mobile Services Switching Centre 

NE Network Element 

NM Network Manager 

NR Network Resource 

NRM Network Resource Model 

OSI Open Systems Interconnection 

PM Performance Management 

RDN Relative Distinguished Name (see 3GPP TS 32.300 [13]) 

RNC Radio Network Controller 

SGSN Serving GPRS Support Node 

SMI Structure of Management Information 

SMS Short Message Service 

SMS-GMSC SMS Gateway MSC 

SMS-IWMSC SMS Interworking MSC 

SNMP Simple Network Management Protocol 

SS Solution Set 

TMN Telecommunications Management Network 

UML Unified Modelling Language 

UMTS Universal Mobile Telecommunications System 

VLR Visitor Location Register 

WBEM Web-Based Enterprise Management 

XML extensible Mark-up Language 
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4 System overview 

4.1 System context 

Figure 2 and Figure 3 identify system contexts of the subject IRP in terms of its implementation called IRP Agent and 
the user of the IRP Agent, called IRPManager. For a definition of IRPManager and IRP Agent, see 3GPP TS 32.102 [2]. 

The IRP Agent implements and supports the Generic Network Resources IRP. The IRP Agent can be an Element 
Manager (EM) or a mediator that interfaces one or more NEs (see Figure 2), or it can be a Network Element (NE) (see 
Figure 3). In the former case, the interfaces (represented by a thick dotted line) between the EM and the NEs are not 
subject of this IRP. 

An IRPManager using this IRP shall choose one of the two System Contexts defined here, for each NE. For instance, if 
an EM is responsible for managing a number of NEs, the NM shall access this IRP through the EM and not directly to 
those NEs. For another IRP though, the System Context may be different. 
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Figure 2: System Context A 
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Figure 3: System Context B 



4.2 Compliance rules 



For general definitions of compliance rules related to qualifiers (Mandatory/Optional/Conditional) for operations, 
notifications and parameters (of operations and notifications) please refer to 3GPP TS 32.102 [2], 

The following defines the meaning of Mandatory and Optional MOC attributes and associations between MOCs, in 
Solution Sets to the Basic CM IRP: 

• The IRPManager shall support all mandatory attributes/associations. The IRPManager shall be prepared to 
receive information related to mandatory as well as optional attributes/associations without failure; however 
the IRPManager does not have to support handling of the optional attributes/associations. 
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• The IRP Agent shall support all mandatory attributes/associations. It may support optional 
attributes/associations. 

An IRP Agent that incorporates vendor-specific extensions shall support normal communication with a 3GPP 
SA5-compliant IRPManager with respect to all Mandatory and Optional managed object classes, attributes, 
associations, operations, parameters and notifications without requiring the IRPManager to have any knowledge of the 
extensions. 

Given that 

• rules for vendor-specific extensions remain to be fully specified, and 

• many scenarios under which IRPManager and IRP Agent interwork may exist, 

it is recognised that in Release 4/5 the IRPManager, even though it is not required to have knowledge of vendor-specific 
extensions, may be required to be implemented with an awareness that extensions can exist and behave accordingly. 
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5 Modelling approach 

This clause identifies the modelling approach adopted and used in this IRP. 
As previously described, this IRP is structured in: 

(1) requirements for a generic Network Resources Model, and 

(2) an IRP Network Resource Model (the subject document) that specifies the interface in a protocol neutral 
manner, and 

(3) a number of IRP Solution Sets that provide the actual definitions of object classes defined in the IRP Network 
Resources Model for each protocol environment. 

Figure 4 shows the structure of the Generic Network Resources IRP (including a number of possible Solution Sets). 



Generic Network Resources IRP: Requirements 



IRP Information Service - operations and notifications (not specified by this 
IRP) 

Network Resource Model (NRM) with MO classes (in UML) 




SNMP 
Solutio 
n Set 



LDAP 

Solutio 

nSet 



WBEM 
Solutio 
n Set 



CORBA 

Solutio 
nSet 



CMIP 
Solutio 
n Set 



Protocol 
independent 



Protocol 
specific 



Figure 4: Generic Network Resources IRP Structure with example Solution Sets 

The Network Resource Model (NRM) 

is a protocol-independent model that specifies a number of Managed Object classes (with attributes and associations), 
which are relevant in the context of the subject IRP. Each Solution Set shall provide an implementation of this resource 
model with: 

a) references to standard models that are applicable for the corresponding protocol environment, and 

b) extensions to these standard models for the parts of the NRM that are not covered. 

The NRM defined in the subject IRP bases its design mainly on work captured in ITU-T M.3100 [4], [5], [6]. However, 
as described in the Scope of the present document (clause 1): The model is highly simplified for the purpose of the NM, 
based on the assumption that all of the detailed CM actions, including fault correction after one or more alarms, are 
performed by an Element Manager which knows the vendor-specific NRM and configuration, and which is launched by 
the NM when necessary. 

Moreover, the classes defined herein are very basic, only for the necessary support of Fault Management (FM) and 
Performance Management (PM), which means that they contain very few attributes - basically only for naming. 

In addition, also some basic associations between some of the classes are defined. 
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Detailed mapping to the actual standard model is described in each Solution Set. It is important to note that if one 
selects a specific management protocol, one should also as base use existing de-facto conventions and standard resource 
models that are applicable to that protocol environment. Examples: 

• SNMP Solution Sets (SMI-specifications) should be consistent with existing standard SNMP MIB-modules in 
order to function in an SNMP environment. 

• CMIP Solution Sets (GDMO-specifications) should be based on standard models like ITU-T X.721 [8] and ITU- 
T M.3100 [4], [5], [6] in order to function in an OSI/TMN environment. 

• WBEM Solution Sets (MOF/XML-specifications) should be based on CIM to function in a WBEM 
environment. 

NOTE: CORBA Solution Sets are special in the sense that no such corresponding de-facto standard models exist, 
and CORBA/IDL is transparent to any model. Thus, one has full freedom to choose the same model for 
the CORBA Solution Set to this IRP, as the IRP Information Model defined herein. 

Finally, all solution sets shall of course be consistent with the IRP Network Resource Model defined herein. 

Clause 6 below defines an information model in terms of Information Object Classes (IOCs), attributes and 
relationships, according to the modelling approach described in TS 32.102 [2]. 



6 Information Object Class definitions 

6.1 Information object classes 

6.1 .1 Information entities imported and local labels 



Label reference 


Local label 


32.111-2, notificatio, notifyAckStateChanged 


notifyAckStateChanged 


32.111-2, notification, notifyChangedAlarm 


notifyChangedAlarm 


32.111-2, notification, notifyClearedAlarm 


notifyClearedAlarm 


32.1 11-2, notification, notifyNewAlarm 


notifyNewAlarm 


32.1 11-2, notification, notifyComments 


notifyComments 


32.662, notification, notifyAttributeValueChanged 


notifyAttributeValueChanged 


32.662, notification, notifyObjectCreation 


notifyObjectCreation 


32.662, notification, notifyObjectDeletion 


notifyObjectDeletion 



6.1.2 Class diagram 

6.1 .2.1 Attributes and relationships 

This sub-clause depicts the set of IOCs that encapsulate information relevant for this service. This sub-clause provides 
the overview of all information object classes in UML. Subsequent subclauses provide more detailed specification of 
various aspects of these information object classes. 
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Figure 5 shows the containment/naming hierarchy and the associations of the generic information object classes defined 
in this TS. 

NOTE: The information object containment relationships are, in the diagram(s) below, indicated by UML 
"Aggregation by reference" ("hollow diamonds"). 
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NOTE 1 : ManagedElement may be contained in either a SubNetwork or an MeContext instance, or have no parent instance at 

all. 
NOTE 2: The listed cardinality numbers represent transient as well as steady-state numbers, and reflect all managed object 

creation and deletion scenarios. 
NOTE 3: Each instance of the VsDataContainer shall only be contained under one MOC. The VsDataContainer can be 

contained under MOCs defined in other NRMs. 
NOTE 4: If the configuration contains several instances of SubNetwork, exactly one SubNetwork instance shall directly or 

indirectly contain all the other SubNetwork instances. 
NOTE 5: The SubNetwork instance not contained in any other instance of SubNetwork is referred to as "the root SubNetwork 

instance". 
NOTE 6: ManagementNode shall be contained in the root SubNetwork instance. 
NOTE 7: If contained in a SubNetwork instance, IRP Agent shall be contained in the root SubNetwork instance. 

Figure 5: Generic NRM Containment/Naming and Association diagram 

Each Managed Object is identified with a Distinguished Name (DN) according to 3GPP TS 32.300 [13] that expresses 
its containment hierarchy. As an example, the DN of a ManagedElement instance could have a format like: 

SubNetwork=Sweden,MeContext=MEC-Gbg-l,ManagedElement=RNC-Gbg-l. 
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6.1.2.2 Inheritance 

This sub-clause depicts the inheritance relationships that exists between information object classes. 
Figure 6 shows the inheritance diagram. 



«InformationObjectClass» 

Top 



«InformationObjectClass» 
ManagedElement 



«InformationObjectClass» 
SubNetwork 



«InformationObjectClass» 
MeContext 



<■ 



«InformationObjectClass» 
ManagedFunction 



«InformationObjectClass» 
ManagementNode 



«InformationObjectClass» 
IRP Agent 



«InformationObjectClass» 
GenericIRP 



Figure 6: Generic Network Resources Model Inheritance Hierarchy 

6.1 .3 Information object class definitions 
6.1.3.1 GenericIRP 



6.1.3.1.1 



Definition 



This information Object Class represents the IRP capability associated with each IRP Agent. This IOC cannot be 
instantiated. It is defined for sub-classing purposes. At least one instance of a sub-class of GenericIRP shall be present 
for every IRP Agent instance. 



6.1.3.1.2 



Attributes 



Table 1 : Attributes of GenericIRP 



Attribute Name 


Support Qualifier 


Read 


Write 


IRPId 


M 


M 


- 



6.1.3.2 



6.1.3.2.1 



IRPAgent 



Definition 



This information Object Class represents the functionality of an IRPAgent. It shall be present. For a definition of 
IRPAgent, see 3GPP TS 32.102 [2]. 

Restriction in R4: The IRPAgent will be contained under a managed object as follows (only one of the options shall be 
used): 

1. ManagementNode, if the configuration contains a ManagementNode; 

2. SubNetwork, if the configuration contains a SubNetwork and no ManagementNode; 

3. ManagedElement, if the configuration contains no ManagementNode or SubNetwork. 
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6.1.3.2.2 



Attributes 



Table 2: Attributes of irp Agent 



Attribute Name 


Support Qualifier 


Read 


Write 


irpAgentld 


M 


M 


- 


system DN 


C 


M 


- 



6.1.3.2.3 



Notifications 



Table 3: Notifications of irp Agent 



Name 


Qualifier 


Notes 


NotifyAckStateChanged 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




NotifyAttributeValueChange 


O 




NotifyChangedAlarm 


See Alarm IRP (3GPP TS 32.1 1 1 -2 [1 1]) 




NotifyClearedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




NotifyNewAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




NotifyObjectCreation 


O 




NotifyObjectDeletion 


O 




NotifyComments 


See Alarm IRP (3GPP TS 32.1 1 1 -2 [1 1]) 





Note that these notifications are issued based on occurrences on the IRP Agent MOC and not on occurrences on other 
Basic CM IRP managed objects. 



6.1.3.3 



ManagedElement 



6.1.3.3.1 



Definition 



This information Object Class represents telecommunications equipment or TMN entities within the 

telecommunications network that performs Managed Element (ME) functions, i.e. provides support and/or service to the 

subscriber. 

An ME communicates with a manager (directly or indirectly) over one or more interfaces for the purpose of being 

monitored and/or controlled. MEs may or may not additionally perform element management functionality. 

An ME contains equipment that may or may not be geographically distributed. An ME is often referred to as a 

"Network Element". This class is similar to the Managed Element class specified in ITU-T M.3100 [4], [5], [6]. 

A ManagedElement may be contained in either a SubNetwork or in an MeContext instance. A single ManagedElement 
seen over the Itf-N may also exist stand-alone with no parent at all. 

The ManagedElement MOC may be used to represent combined ME functionality (as indicated by the 
managedElementType attribute and the contained instances of different functional MOCs). 

Single function ManagedElement managed object instances will have a 1..1 containment relationship to a function 
Managed Object (in this context a function MO is an MO derived from the ManagedFunction MOC). Multiple function 
ManagedElement managed object instances will have a 1..N containment relationship to function Managed Objects. 
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6.1.3.3.2 



Attributes 



Table 4: Attributes of ManagedElement 



Attribute Name 


Support Qualifier 


Read 


Write 


ManagedElementld 


M 


M 


- 


DnPrefix 


C 


M 


- 


ManagedElementType 


M 


M 


- 


UserLabel 


M 


M 


M 


VendorName 


M 


M 


- 


UserDefinedState 


M 


M 


M 


LocationName 


M 


M 


- 


SwVersion 


M 


M 


- 



6.1.3.3.3 



Notifications 



Table 5: Notifications of ManagedElement 



Name 


Qualifier 


Notes 


notifyAckStateChanged 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyAttributeValueChange 


O 




notifyChangedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyClearedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyNewAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyObjectCreation 


O 




notifyObjectDeletion 


O 




notifyComments 


See Alarm IRP (3GPP TS 32.111-2 [11]) 





6.1.3.4 



ManagedFunction 



6.1.3.4.1 



Definition 



This information Object Class is provided for sub-classing only. It provides attribute(s) that are common to functional 
Information Object Classes. Note that a Managed Element may contain several managed functions. The 
ManagedFunction may be extended in the future if more common characteristics to functional objects are identified. 



6.1.3.4.2 



Attributes 



Table 6: Attributes Of ManagedFunction 



Attribute Name 


Support Qualifier 


Read 


Write 


UserLabel 


M 


M 


M 



6.1.3.5 



ManagementNode 



6.1.3.5.1 



Definition 



This information Object Class represents a telecommunications management system (EM) within the TMN that 
contains functionality for managing a number of Managed Elements (MEs). The management system communicates 
with the MEs directly or indirectly over one or more interfaces for the purpose of monitoring and/or controlling these 
MEs. 

This class has similar characteristics as the ManagedElement. The main difference between these two classes is that the 
ManagementNode has a special association to the managed elements that it is responsible for managing. 
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6.1.3.5.2 



Attributes 



Table 7: Attributes Of ManagementNode 



Attribute Name 


Support Qualifier 


Read 


Write 


ManagementNodeld 


M 


M 


- 


UserLabel 


M 


M 


M 


VendorName 


M 


M 


- 


UserDefinedState 


M 


M 


M 


LocationName 


M 


M 


- 


SwVersion 


M 


M 


- 



6.1.3.5.3 



Notifications 



Table 8: Notifications Of ManagementNode 



Name 


Qualifier 


Notes 


NotifyAckStateChanged 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




NotifyAttributeValueChange 


O 




NotifyChangedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




NotifyClearedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




NotifyNewAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




NotifyObjectCreation 


O 




NotifyObjectDeletion 


O 




NotifyComments 


See Alarm IRP (3GPP TS 32.111-2 [11]) 





6.1.3.6 



MeContext 



6.1.3.6.1 



Definition 



This information Object Class is introduced for naming purposes. It may support creation of unique DNs in scenarios 
when some MEs have the same RDNs due to the fact that they have been manufacturer pre-configured. 
If some MEs have the same RDNs (for the above mentioned reason) and they are contained in the same SubNetwork 
instance, some measure shall be taken in order to assure the global uniqueness of DNs for all MOIs under those MEs. 
One way could be to set different DnPrefixes for those NEs, but that would require either that: 

a) all LDNs or DNs are locally modified using the new DnPrefix for the upper portion of the DNs, or 

b) a mapping (translation) of the old LDNs or DNs to the new DNs every time they are used externally, e.g. in alarm 
notifications. 

As both the two alternatives above may involve unacceptable drawbacks (as the old RDNs for the MEs then would have 
to be changed or mapped to new values), using MeContext offers a new alternative to resolve the DN creation. Using 
MeContext as part of the naming tree (and thus the DN) means that the DnPrefix, including a unique MeContext for 
each ME, may be directly concatenated with the LDNs, without any need to change or map the existing ME RDNs to 
new values. 

MeContext have 0..N instances. It may exist even if no SubNetwork exists. Every instance of MeContext contains 
exactly one ManagedElement during steady-state operations. 



6.1.3.6.2 



Attributes 



Table 9: Attributes of MeContext 



Attribute Name 


Support Qualifier 


Read 


Writre 


MeContextld 


M 


M 


- 


DnPrefix 


C 


M 


- 
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6.1.3.6.3 



Notification 



Table 10: Notifications of MeContext 



Name 


Qualifier 


Notes 


notifyAckStateChanged 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyAttributeValueChange 


O 




notifyChangedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyClearedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyNewAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyObjectCreation 


O 




notifyObjectDeletion 


O 




notifyComments 


See Alarm IRP (3GPP TS 32.111-2 [11]) 





6.1.3.7 



SubNetwork 



6.1.3.7.1 Definition 

This information object class represents a set of managed entities as seen over the Itf-N. 

There may be zero or more instances of a SubNetwork. It shall be present if either a ManagementNode or multiple 
ManagedElements are present (i.e. ManagementNode and multiple ManagedElement instances shall have SubNetwork 
as parent). 

The SubNetwork instance not contained in any other instance of SubNetwork is referred to as "the root SubNetwork 
instance". 



6.1.3.7.2 



Attributes 



Table 1 1 : Attributes of SubNetwork 



Attribute Name 


Support Qualifier 


Read 


Write 


SubNetworkld 


M 


M 


- 


DnPrefix 


C 


M 


- 


UserLabel 


M 


M 


M 


userDefinedNetworkType 


M 


M 


- 



6.1.3.7.3 



Notification 



Table 12: Notifications of SubNetwork 



Name 


Qualifier 


Notes 


notifyAckStateChanged 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyAttributeValueChange 


O 




notifyChangedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyClearedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyNewAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyObjectCreation 


O 




notifyObjectDeletion 


O 




notifyComments 


See Alarm IRP (3GPP TS 32.111-2 [11]) 





6.1.3.8 



Top 



6.1.3.8.1 



Definition 



This information object class is introduced for generalisation purposes. All information object classes defined in all TS 
that claim to be conformant to 32. 102[2] shall inherit from Top. 
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6.1.3.8.2 



Attributes 



Table 13: Attributes of Top 



Attribute Name 


Support Qualifier 


Read 


Write 


objectClass 


M 


M 


- 


objectlnstance 


M 


M 


- 



6.1.3.9 



Class VsDataContainer 



6.1.3.9.1 



Definition 



The 'VsDataContainer' managed object is a container for vendor specific data. The number of instances of the 
'VsDataContainer' can differ from vendor to vendor. This MOC shall only be used by the Bulk CM IRP for the 
UTRAN, GERAN and CN object models. 



6.1.3.9.2 



Attribute 



Table 14: Attributes Of VsDataContainer 



Name 


Qualifier 


Read 


Write 


VsDataContainerld 


M 


M 


- 


VsDataType 


M 


M 


- 


VsData 


M 


M 


M 


VsDataFormatVersion 


M 


M 


- 



6.1 .4 Information relationship definitions 



6.1.4.1 



MgmtAssociation (M) 



6.1.4.1.1 



Definition 



This association is used to represent relationships between one or more MEs and the ManagementNode that is 
responsible for managing the MEs. It has two roles, named Manages and ManagedBy. The role 'Manages' models the 
fact that a ManagementNode is responsible for managing zero or more MEs, and the role ManagedBy models the fact 
that an ME is managed by zero or one ManagementNode. Each role is in the MOC definition mapped to a reference 
attribute with the same name. 

6.1.4.1.2 Roles 

The roles involved in the relation MgmtAssociation are listed in this table. 

Table 14: Roles of the relation MgmtAssociation 



Name 


Definition 


Manages 


This role refers to a list of the DN(s) of the related ManagedElement instance(s). This is a reference 
attribute modelling the role (of the association MgmtAssociation) that this managementNode is 
responsible for managing zero or more MEs. 


IsManagedBy 


This role refers to the DN of the related managementNode instance. This is a reference attribute 
modelling the role (of the association MgmtAssociation) that this ME is managed by zero or one 
managementNode. 



6.1.4.1.3 Constraints 

There is no constraint for this relationship. 



ETSI 



3GPP TS 32.622 version 5.0.0 Release 5 



21 



ETSI TS 132 622 V5.0.0 (2002-09) 



6.1 .4.2 SubNetwork-ManagementNode 

6.1.4.2.1 Definition 

This represents the containment relationship between SubNetwork and ManagementNode. 

6.1.4.2.2 Roles 



Name 


Definition 


contains 


This role is played by objects of the information object class ManagementNode. 


isContainedln 


This role is played by objects of the information object class SubNetwork. 



6.1.4.2.3 



Constraints 



Name 


Definition 


ManagementNodeContai 
nedlnRootSubNetwork 


"An instance of the ManagementNode IOC shall be contained in the root SubNetwork 
instance." 



6.1.4.3 



SubNetwork-MeContext 



6.1.4.3.1 Definition 

This represents the containment relationship between SubNetwork and MeContext. 

6.1.4.3.2 Roles 



Name 


Definition 


contains 


This role is played by objects of the information object class MeContext. 


isContainedln 


This role is played by objects of the information object class SubNetwork. 



6.1.4.3.3 Constraints 

There is no constraint for this relationship. 

6.1.4.4 SubNetwork-SubNetwork 

6.1.4.4.1 Definition 

This represents the containment relationship between SubNetwork and SubNetwork. 

6.1.4.4.2 Roles 



Name 


Definition 


contains 


This role is played by objects of the information object class SubNetwork. 


isContainedln 


This role is played by objects of the information object class SubNetwork. 



6.1.4.4.3 



Constraints 



Name 


Definition 


OneSubNetworkContain 
sAIIOthers 


" If the configuration contains several instances of the SubNetwork IOC, exactly one 
SubNetwork instance shall directly or indirectly contain all the other SubNetwork instances. " 
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6.1.4.5 SubNetwork-IRPAgent 

6.1.4.5.1 Definition 

This represents the containment relationship between SubNetwork and IRP Agent. 

6.1.4.5.2 Roles 



Name 


Definition 


contains 


This role is played by objects of the information object class IRPAgent. 


isContainedln 


This role is played by objects of the information object class SubNetwork. 



6.1.4.5.3 



Constraints 



Name 


Definition 


IRPAgentContainedlnRo 
otSubNetwork 


" If an instance of the IRPAgent IOC is contained in a SubNetwork instance, this instance 
shall be the root SubNetwork instance. " 



6.1 .4.6 SubNetwork-ManagedElement 

6.1.4.6.1 Definition 

This represents the containment relationship between SubNetwork and ManagedElement. 

6.1.4.6.2 Roles 



Name 


Definition 


contains 


This role is played by objects of the information object class ManagedElement. 


isContainedln 


This role is played by objects of the information object class SubNetwork. 



6.1.4.6.3 Constraints 

There is no constraint for this relationship. 

6.1.4.7 MeContext-ManagedElement 

6.1.4.7.1 Definition 

This represents the containment relationship between MeContext and ManagedElement. 

6.1.4.7.2 Roles 



Name 


Definition 


Contains 


This role is played by objects of the information object class ManagedElement. 


IsContainedln 


This role is played by objects of the information object class MeContext. 



6.1.4.7.3 Constraints 

There is no constraint for this relationship. 



6.1.4.8 



ManagedElement-IRPAgent 



6.1.4.8.1 Definition 

This represents the containment relationship between ManagedElement and IRPAgent. 
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6.1.4.8.2 



Roles 



Name 


Definition 


Contains 


This role is played by objects of the information object class IRPAgent. 


IsContainedln 


This role is played by objects of the information object class ManagedElement. 



6.1.4.8.3 Constraints 

There is no constraint for this relationship. 

6.1.4.9 IRPAgent-GenericIRP 

6.1.4.9.1 Definition 

This represents the containment relationship between IRPAgent and GenericIRP. 

6.1.4.9.2 Roles 



Name 


Definition 


Contains 


This role is played by objects of the information object class GenericIRP. 


IsContainedln 


This role is played by objects of the information object class IRPAgent. 



6.1.4.9.3 Constraints 

There is no constraint for this relationship. 

6.1 .5 Information attribute definitions 
6.1 .5.1 Definitions and legal values 

The table below defines the attributes that are present in several information object classes of the present document. 
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Table 15: Attributes 



Attribute Name 


Definition 


Legal Values 


dnPrefix 


It carries the DN Prefix information as defined in Annex C of 32.300 
[1 3]. It shall only be specified if the instance of the information object 
class supporting this attribute is a local root instance of the MIB. 
Otherwise the value shall carry the NULL semantics. 




managedElementld 


An attribute whose 'name+value' can be used as an RDN when naming 
an instance of the ManagedElement object class. This RDN uniquely 
identifies the object instance within the scope of its containing (parent) 
object instance. 




managedElementType 


The type of managed element. It is a multi-valued attribute with one or 
more elements. Thus, it may represent one ME functionality, e.g. an 
RNC, or a combination of more than one functionality e.g. an 
MSC/HLR. 

The actual syntax and encoding of this attribute is Solution Set specific. 


RNC, NodeB, BSS, 
MSC, HLR, VLR, AuC, 
EIR, SMS-IWMSC, 
SMS-GMSC, GMSC, 
SGSN, GGSN, BG, 
BS, CBC, CGF, 
GMLC, GMSC Server, 
IWF, MGW, MNP- 
SRF, MSC Server, 
NPDB, R-SGW, SCF, 
SMLC, SRF, SSF. 


irpAgentld 


An attribute whose 'name+value' can be used as an RDN when naming 
an instance of this object class. This RDN uniquely identifies the object 
instance within the scope of its containing (parent) object instance. 




irpld 


An attribute whose 'name+value' can be used as an RDN when naming 
an instance of this object class. This RDN uniquely identifies the object 
instance within the scope of its containing (parent) object instance. 




locationName 


The physical location of this entity (e.g. an address). 




managementNodeld 


An attribute whose 'name+value' can be used as an RDN when naming 
an instance of this object class. This RDN uniquely identifies the object 
instance within the scope of its containing (parent) object instance. 




meContextld 


An attribute whose 'name+value' can be used as an RDN when naming 
an instance of this object class. This RDN uniquely identifies the object 
instance within the scope of its containing (parent) object instance. 




objectClass 


An attribute which captures the name of the class from which the object 
instance is an occurrence of. 




objectlnstance 


An information which captures the Distinguished Name of any object. 




subNetworkld 


An attribute whose 'name+value' can be used as an RDN when naming 
an instance of the SubNetwork object class. This RDN uniquely 
identifies the object instance within the scope of its containing (parent) 
object instance. 




swVersion 


The software version of the ManagementNode or ManagedElement 
(this is used for determining which version of the vendor specific 
information is valid for the ManagementNode or ManagedElement). 




systemDN 


The Distinguished Name (DN) of IRPAgent. defined in 3GPP 
TS.32.300. 




userDefinedNetworkType 


Textual information regarding the type of network, e.g. UTRAN. 




userDefinedState 


An operator defined state for operator specific usage. (See also Note 
below) 




userLabel 


A user-friendly name of this object. 




vendorName 


The name of the vendor. 




vsData 


Vendor specific attributes of the type vsDataType. The attribute 
definitions including constraints (value ranges, data types, etc.) are 
specified in a vendor specific data format file. 




vsDataContainerld 


An attribute whose 'name+value' can be used as an RDN when naming 
an instance of this object class. This RDN uniquely identifies the object 
instance within the scope of its containing (parent) object instance. 




vsDataFormatVersion 


Name of the data format file, including version. 




vsDataType 


Type of vendor specific data contained by this instance, e.g. relation 
specific algorithem parameters, cell specific parameters for pewer 
control or re-selection or a timer. The type itself is also vendor specific. 
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Annex A (informative): 
MOC name recommendation 



Recommendation: 

3GPP considers the use of many non-alphanumeric characters as valid characters for constructing the MOC name. The 
Java programming language considers the use of alphanumeric characters plus only two non-alphanumeric characters, 
i.e. "$" and "_", as valid characters for Java Packages and Java Class names. Because the names of the Java Packages 
and Java Classes generated by Java programming tools may include MO Class names, a Java environment would have 
to include a translation mechanism that replaces the invalid characters (if they are used by the MOC author to name a 
MOC) to valid characters. For example, replace "-" to "_". This translation mechanism causes unwanted complexity and 
reduction in performance of the implementation. Given Java may become popular for coding IRP Manager and/or IRP 
Agent capabilities, this note recommends the MOC author to use valid Java name characters (i.e. all alphanumeric 
characters plus "$" and "_") to name their MOCs. 



ETSI 



3GPP TS 32.622 version 5.0.0 Release 5 



26 



ETSI TS 132 622 V5.0.0 (2002-09) 



Annex B (informative); 
Change history 



Change history 


Date 


TSG# 


TSG Doc. 


CR 


Rev 


Subject/Comment 


Old 


New 


Jun 2001 


S 12 


SP-010283 


-- 


-- 


Approved at TSG SA #12 and placed under Change Control 


2.0.0 


4.0.0 


Sep 2001 


S_13 


SP-010479 


001 




Add the notification notifyComments in all MOCs that support 
alarms and correct the list of allowed members of the attribute 
managedElementType of the MOC managedElement 


4.0.0 


4.1.0 


Sep 2001 


S_13 


SP-010479 


002 


— 


Correction of Generic NRM Containment/Naming and Association 
diagram 


4.0.0 


4.1.0 


Sep 2001 


S_13 


SP-010479 


003 


-- 


Correct description of swVersion attribute 


4.0.0 


4.1.0 


Mar 2002 


S_15 


SP-020020 


004 


— 


Addition of managedElementType value for GSM Radio Access 
Network support 


4.1.0 


4.2.0 


Jun 2002 


S_16 


SP-020299 


005 


— 


Remove R99-inherited restriction of self-containment for MOC 
SubNetwork 


4.2.0 


4.3.0 


Sep 2002 


S 17 


SP-020488 


006 


-- 


Upgrade to Rel-5 (Add new IS method, MOC name convention) 


4.3.0 


5.0.0 
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